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Abstract 

The  widespread  availability  of  the  TCP/IP  proto¬ 
cols  in  early  versions  of  BSD  UNIX  fostered  the 
currently  widespread  use  of  those  protocols  in  com¬ 
mercial  products.  Rapid  depletion  of  the  IPv4  ad¬ 
dress  space  has  caused  the  Internet  Engineering  Task 
Force  to  design  version  6  of  the  Internet  Protocol 
(IPv6).  IPv6  has  some  similiarities  with  IPv4,  but 
it  also  has  many  differences,  most  notably  in  address 
size.  This  paper  describes  our  experience  creating  a 
freely  distributable  implementation  of  IPv6  inside 
4.4  BSD,  with  focus  on  the  areas  that  have  changed 
between  the  IPv4  and  IPv6  implementations. 

1  Introduction 

During  the  past  decade,  the  worldwide  Internet  has 
grown  at  exponential  rates,  not  only  in  North  Amer¬ 
ica  but  also  in  Europe  and  Asia.  [Lot92]  This,  com¬ 
bined  with  suboptimal  address  allocation  practices, 
has  led  to  increasing  depletion  of  the  IP  version  4 
(IPv4)  address  space.  One  direct  result  of  the  IPv4 
address  depletion  was  that  the  Internet  Engineer¬ 
ing  Task  Force  (IETF),  began  working  to  create  a 
revised  version  of  the  Internet  Protocol  (IP).  This 
effort  is  called  Next-Generation  IP  (IPng).  The  re¬ 
sulting  protocol  is  IP  version  6  (IPv6).  When  the 
IPng  effort  began,  there  were  several  contenders,  but 
in  July  1994  the  SIPP  proposal  became  the  primary 
basis  for  IPv6. 

The  widespread  availability  of  TCP/IPv4  in  early 
versions  of  BSD  UNIX  was  crucial  to  the  success  and 
deployment  of  the  Internet  technologies.  In  order 
to  help  make  Next-Generation  IP  as  widely  avail¬ 
able,  the  authors  began  working  with  the  Simple  In¬ 
ternet  Protocol  (SIP)  Working  Group  of  the  IETF 
in  1992.[Dee93]  As  SIP  evolved  into  SIPP  [Hin94] 
and  then  into  IPv6,  the  authors  began  prototyping, 
initially  in  BSD  Net/2  and  currently  in  4.4  BSD. 

^Although  Craig  W.  Metz  is  with  Kaman  Sciences  Corpo¬ 
ration,  he  may  be  reached  at  NRL. 


Our  primary  development  systems  were  Sun  SPARC 
workstations  and  i486  systems  running  4.4  BSD  1. 

Implementation  issues,  rather  than  the  details  of 
the  IPv6  protocol,  are  the  focus  of  this  paper.  A 
number  of  implementation  issues  arose  with  IPv6 
and  have  been  resolved.  Obvious  issues,  such  as 
supporting  128  bit  addresses  instead  of  32  bit  ad¬ 
dresses,  are  discussed  in  addition  to  the  less  obvious 
issues  of  how  to  implement  IPv6  security  inside  a 
BSD  kernel.  We  assume  that  the  reader  is  some¬ 
what  familiar  with  the  IPv6  protocol  [DH95]  and 
the  4.4  BSD-Lite  implementation  of  IPv4.  Figure  1 
shows  a  rough  overview  of  4.4  BSD-Lite’s  Internet 
implementation,  along  with  some  of  the  new  mod¬ 
ules  for  IPv6.  To  add  a  new  version  of  IP,  many  of 
the  surrounding  modules  had  to  be  modified  as  well. 


2  Changes  in  Basic  IP  Functions 
2.1  Differences  in  packet  format 

Perhaps  the  most  obvious  difference  between  IPv6 
and  its  predecessor  is  the  packet  format.  Although 
some  in  the  Internet  community  felt  that  64  bit  ad¬ 
dresses  were  sufficiently  large,  others  insisted  that 
128-bit  addresses  were  needed  so  that  plug-and-play 
address  assignment  similar  to  ISO  ES-IS  could  be 
supported.  Many  of  the  IPv4  header  Helds  that 
were  unused  in  practice  (Figure  2)  were  eliminated 
or  moved  to  options,  making  the  IPv6  base  header 
(Figure  3)  more  streamlined.  One  significant  ad¬ 
dition  to  the  header  is  the  Flow  Identifier  which 
is  an  important  hook  for  resource  reservation  tech¬ 
niques  [ZBE+93]  currently  being  developed  within 
the  IETF. 

The  sparse  IPv6  header  is  optimized  for  minimal 
processing.  An  IPv6  router  needs  only  to  verify 
the  version  number,  inspect  the  destination  address, 

1The  systems  running  4.4  BSD  (encumbered)  have  had 
the  4.4  BSD-Lite  networking  changes  incorporated  into  them. 
Some  call  this  a  BSD  Net/3  system. 
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Figure  1:  Simple  Overview  of  4.4  BSD-Lit.e  Internet 
Modules 

decrement  the  hop  counter,  and  process  hop-by-hop 
options  if  they  are  present.  (The  flow  label  can  be 
used  to  optimize:  this  process  further.)  An  IPv4 
router  has  to  perform  everything  an  IPv6  router 
does,  as  well  as  verify  and  recompute  the  header 
checksum,  and  fragment  the  datagram  further  if 
needed.  An  IPv6  destination  host  initially  only  has 
to  check  the  validity  of  the  version  and  destination 
address.  If  there  are  options,  they  are  daisy-chained 
and  indicated  by  the  Next  Header  field.  Otherwise,  a 
higher-level  protocol  (e.g.  TCP)  is  the  next  header 
processed.  An  IPv4  destination  host  has  to  verify 
not  only  the  version  and  destination  address,  but 
the  IP  header  checksum  as  well. 


2.2  Protocol  Processing 

A  number  of  the  more  recently  developed  IPv4  op¬ 
tional  features  are  mandatory  in  IPv6.  Other  fea¬ 
tures,  such  as  cryptographic  security,  are  new  with 
IPv62.  These  have  caused  a  number  of  changes  in 
IP  protocol  processing. 

IPv6  daisy-chains  optional  headers  after  the  base 
header.  Our  implementation  pre-parses  an  IP  packet 
into  its  constituent  headers  and  upper-layer  proto- 

2  The  cryptographic  security  recently  standardised  for  IPv4 
and  IPv6  was  originally  designed  for  use  with  IPv6  and  later 
adapted  for  use  with  IPv4. 


col  data  as  part  of  the  initial  IPv6  input  processing. 
Although  this  does  degrade  performance,  it  has  sim¬ 
plified  the  processing  of  optional  IPv6  headers.  We 
plan  to  create  a  fast  path  around  the  preparsing  code 
for  packets  containing  no  optional  headers. 

The  Path  MTU  Discovery  [MD90]  technique  for 
avoiding  IP  fragmentation  in  routers  is  mandatory 
for  IPv6.  IPv6  does  not  have  any  intermediate  frag¬ 
mentation  and  instead  relies  on  Path  MTU  Discov¬ 
ery  and  end-to-end  fragmentation.  Our  implemen¬ 
tation  stores  Path  MTU  information  in  host  routes. 
Host  routes  are  automatically  created  for  IP  commu¬ 
nications  originating  on  the  local  machine.  Storing 
this  information  in  the  routing  table  makes  this  data 
available  to  TCP,  UDP,  and  ICMP.  IPv6  requires  a 
minimum  MTU  of  576  bytes,  which  is  much  larger 
than  the  68  byte  minimum  MTU  of  IPv4.  How¬ 
ever,  even  this  larger  size  might  be  too  small  if  cer¬ 
tain  IPv6  options,  such  as  the  Hop-by-Hop  Options 
Header  (which  can  be  up  to  2048  octets),  are  used. 
In  such  cases,  end-to-end  fragmentation  will  be  re¬ 
quired. 

3  Security  Processing 

Two  cryptographic  security  mechanisms  have  been 
defined  for  IPv6  [At.k95c].  One,  known  as  the  Au¬ 
thentication  Header  (AH),  provides  authentication 
without  confidentiality [At.k95a].  The  second,  known 
as  the  Encapsulating  Security  Payload  (ESP),  pro¬ 
vides  confidentiality  through  encryption  of  packet 
contents.  [At.k95b]  ESP  has  two  modes.  The  first 
mode,  known  as  Transport-mode ,  encrypts  only  the 
upper-layer  header  and  data  (such  as  TCP,  UDP,  or 
ICMP)  and  leaves  the  IP  header  in  the  clear.  The 
second  mode,  known  as  Tunnel-mode ,  encrypts  an 
entire  IP  datagram,  prepending  an  additional  clear¬ 
text  IP  header  outside  the  encrypted  IP  datagram  so 
that  the  packet  can  be  routed.  The  implementation 
of  these  mechanisms  broke  new  ground  within  the 
BSD  kernel.  In  addition  to  implementing  the  Au¬ 
thentication  Header  and  both  modes  of  ESP,  we  also 
implemented  the  kernel  support  required  to  manage 
network  security  associations,  including  the  crypto¬ 
graphic  keys. 

The  IPv6  security  mechanisms  can  use  any  appro¬ 
priate  encryption  or  authentication  algorithm.  The 
mandatory  algorithms  for  a  compliant  implemen¬ 
tation  are  keyed  MD5[MKS95b]  for  authentication, 
and  DES-CBC[MKS95a]  for  encryption.  Both  algo¬ 
rithms  are  in  this  implementation.  To  implement 
a  new  ESP  or  AH  algorithm,  the  kernel  must  be 
recompiled  with  support  for  the  new  algorithms  in 
place.  Other  algorithms,  such  as  t.riple-DES,  are  be- 
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Figure  3:  IPv6  Packet  Format 


ing  implemented  by  others.  Later  in  this  paper,  we 
discuss  why  it  is  straightforward  to  add  support  for 
additional  cryptographic  algorithms. 

Both  ESP  Transport-mode  encryption  and  Au¬ 
thentication  Header  output  processing  are  normally 
performed  immediately  before  any  fragmentation  on 
outgoing  packets  and  after  reassembly  on  the  input 
side.  They  are  done  this  way  because,  except  for 
fragmentation,  they  need  to  operate  on  the  packet 
as  it  will  appear  on  the  wire.  For  example,  the  source 
address  for  the  packet  from  a  multi-homed  system 
must  be  known  before  encryption  or  authentication 
can  take  place. 

3.1  Security  Associations 

A  fundamental  concept  behind  IP  security  is  the  Se¬ 
curity  Association.  A  Security  Association  contains 
all  of  the  configuration  data  for  a  particular  secure 
session  between  two  or  more  systems  communicating 
via  IP.  For  example,  the  security  services  in  use  (AH 
or  ESP),  the  cryptographic  algorithm(s)  in  use,  the 
cryptographic  key(s)  in  use,  the  key  lifetimes,  the 
Security  Parameters  Index  (SPI),  and  the  sensitiv¬ 
ity  level  (e.g.  Unclassified,  Secret)  of  the  session  are 
all  components  of  a  Security  Association.  In  order 
to  support  multicast  as  well  as  unicast,  all  Security 
Associations  are  one-way  from  source  to  destination. 
So  a  typical  telnet  session  would  need  two  Security 
Associations,  one  in  each  direction. 

Security  associations  are  stored  in  a  table  inside 
the  kernel.  A  module  called  the  Key  Engine  controls 
access  to  the  table.  The  Key  Engine  allows  kernel 
services,  such  as  the  IPv6  module,  to  obtain  secu¬ 


rity  associations  for  inbound  and  outbound  packets. 
The  Key  Engine  also  communicates  with  user-level 
key  management  programs  so  that  key  management 
may  be  implemented  properly.  The  relationship  be¬ 
tween  the  key  engine  and  user-level  key  management 
programs  is  similar  to  the  relationship  between  the 
routing  socket  [Skl91]  and  programs  such  as  gated (8). 

3.2  Security  Processing  Structure 

The  authentication  processing  function  is  split  into 
three  major  parts.  The  first,  a  keyed  message  di¬ 
gest  function,  is  selected  on  a  per-association  basis 
through  an  algorithm  switch  that  calls  the  appropri¬ 
ate  computation  function.  The  second,  the  header 
processing  routines,  finds  the  appropriate  security 
association  and  policy  actions  for  the  packet  and  ei¬ 
ther  builds  or  parses  the  actual  option  header  for 
authentication.  The  third  part  is  the  meat  of  the  au¬ 
thentication  function.  This  routine  walks  the  packet, 
header  by  header,  zeroing  header  fields  that  vary 
unpredictably  end-to-end,  and  passing  other  header 
fields  and  the  packet  data  into  the  keyed  message  di¬ 
gest  function.  The  resulting  message  digest  data  can 
be  either  inserted  into  the  outgoing  header  or,  in  the 
case  of  an  incoming  packet,  checked  with  the  one  in 
the  header.  The  keyed  message  digest  functions  are 
treated  in  the  AH  calculation  function  as  stream  op¬ 
erations;  any  necessary  blocking  and  padding  must 
be  handled  by  the  implementation  of  the  keyed  mes¬ 
sage  digest  functions. 

The  encryption  processing  function  is  split  into 
similar  parts.  The  first,  an  encryption/decryption 
function,  and  the  second,  a  transform  header  con- 


struction  and  parsing  function,  are  selected  on  a 
per-association  basis  through  an  algorithm  switch. 
Because  almost  all  of  the  header  format  can  vary 
depending  on  which  cryptographic  transform  is  be¬ 
ing  used,  it  is  necessary  that  both  the  cryptographic 
functions  and  the  header  processing  functions  be 
switchable.  There  is  a  generic  reblocking  function 
that  runs  a  specified  encryption  or  decryption  func¬ 
tion  over  the  data  while  arranging  it  into  properly 
sized  blocks.  Block-oriented  encryption  and  decryp¬ 
tion  functions  require  the  encrypted  data  to  be  an 
integral  number  of  cryptographic  blocks. 

3.3  Output  Security  Processing 

Immediately  before  IP  fragmentation  is  performed, 
ipv6_output  ( )  calls  an  IP  security  output  pol¬ 
icy  function,  ipsec_output_policy  ( ) ,  to  determine 
whether  this  packet  needs  security.  This  function 
examines  the  system  security  level  configured  by  the 
administrator  and  the  socket  security  level  requested 
by  the  process  on  the  socket.  The  function  is  able  to 
examine  the  socket  security  level  because  each  out¬ 
going  packet  data  chain  now  contains  a  back  pointer 
to  the  socket  that  sent  the  packet.  The  security 
output  policy  function  then  examines  the  system- 
wide  security  policy  and  the  socket-requested  secu¬ 
rity  policy  and  applies  the  more  paranoid  of  these 
policies  to  the  outgoing  packet. 

The  ipsec_output_policy ( )  function  is  also  re¬ 
sponsible  for  making  the  getassocbysocket  ( )  call 
into  the  Key  Engine  to  obtain  Security  Association 
data  for  the  outgoing  packet.  If  the  Key  Engine  has 
the  appropriate  Security  Associations,  it  provides 
access  to  them.  If  no  appropriate  Security  Associ¬ 
ation  exists  and  a  key  management  daemon  is  run¬ 
ning,  then  the  Key  Engine  sends  a  Request  message 
to  that  daemon  and  informs  the  output  policy  func¬ 
tion  that  the  Security  Association  has  been  delayed. 
If  no  appropriate  Security  Association  exists  and  no 
key  management  daemon  is  running,  then  the  Key 
Engine  returns  an  error  to  ipsec_output .policy (). 
If  this  error  occurs,  it  will  eventually  be  presented  to 
the  user  as  the  newly  defined  IP  Security  processing 
error,  EIPSEC. 

If  IP  security  is  needed  and  all  appropriate  secu¬ 
rity  information  is  available  for  the  outgoing  packet, 
then  the  output  security  policy  function  will  return 
both  an  indication  of  which  services  are  needed  and 
pointers  to  the  appropriate  Security  Associations. 
The  IP  Output  function  then  makes  the  appropriate 
calls  to  apply  outgoing  security  services  and  then 
sends  the  packet  out.  If  any  errors  occur  during  se¬ 
curity  output  processing,  the  packet  will  be  dropped 


and  the  user  will  be  given  the  EIPSEC  error  men¬ 
tioned  above.  In  the  future,  we  might  enhance  the 
getassocbysocket!)  call  to  provide  the  user  iden¬ 
tification  or  uid  associated  with  the  network  socket 
so  that  the  Key  Engine  can  provide  finer  granularity 
of  keying.  The  current  implementation  does  support 
both  shared  (i.e.  host-oriented)  keys  and  also  unique 
(i.e.  socket-oriented)  keys. 

3.4  Input  Security  Processing 

For  incoming  packets,  the  task  is  significantly  eas¬ 
ier.  When  an  Authentication  Header  or  Encap¬ 
sulating  Security  Payload  header  is  encountered, 
it  is  processed  by  calling  the  appropriate  IP  se¬ 
curity  input  function  (either  ipsec_ah_input  ( )  or 
ipsec_esp_input()).  That  function  reads  the  Secu¬ 
rity  Parameters  Index  (SPI)  contained  in  the  clear¬ 
text  portion  of  the  received  packet  and  makes  a 
getassocbyspi ( )  call  into  the  Key  Engine  to  ob¬ 
tain  the  correct  Security  Association  for  the  received 
packet.  If  this  call  succeeds,  the  security  input  pro¬ 
cessing  is  performed  and  the  appropriate  security- 
related  flag  is  set.  The  packet  data  chain  has  two 
new  flags,  both  initially  cleared  on  input,  called 
M .AUTHENTIC  and  M .DECRYPTED.  These  flags  indicate 
that  the  packet  passed  authentication  processing 
and  encryption  processing,  respectively.  If  any  se¬ 
curity  input  processing  fails,  the  packet  is  dropped 
and  appropriate  kernel  statistics  counters  are  incre¬ 
mented.  A  modified  netstat(8)  is  supplied  that  can 
display  these  statistics  for  the  system  administrator. 
If  more  than  one  form  of  security  has  been  applied, 
then  the  packet  will  go  through  more  than  one  secu¬ 
rity  input  processing  function. 

The  input  security  processing  code  also  performs 
special  checks  comparing  the  outer  IP  source  address 
and  the  (previously  encrypted)  inner  IP  source  ad¬ 
dress  for  the  case  when  an  IP  datagram  is  tunnelled 
inside  another  IP  datagram  and  either  the  Authen¬ 
tication  Header  or  the  Encapsulating  Security  Pay- 
load  is  present.  These  checks  are  intended  to  prevent 
an  adversary  system  from  encapsulating  a  forged 
packet  inside  an  authenticated  or  encrypted  legiti¬ 
mate  packet  and  tricking  the  receiving  system  into 
believing  the  forged  packet  was  authentic.  If  these 
source  address  checks  fail,  then  the  M.AUTHENTIC  or 
M.DECRYPTED  flags  on  the  received  packet  data  chain 
are  cleared. 

After  security  input  processing  is  completed,  the 
normal  input  processing  resumes.  Once  the  packet 
reaches  the  transport  layer,  the  transport  layer’s 
input  function,  for  example  tcp.input  ( ) ,  calls 
ipsec_input_policy()  to  perform  an  input  secu- 


rity  policy  check.  The  incoming  packet  is  dropped 
if  it  does  not  meet  the  requirements  for  authenti¬ 
cation  or  encryption  that  exist  for  its  destination 
socket.  Because  ipsec_input_policy ( )  checks  not 
only  the  socket  security  requirements  but  also  the 
system- wide  security  requirements,  the  system  ad¬ 
ministrator  can  mandate  a  minimum  security  level 
for  all  normal  network  connections. 


3.5  Policy  Separation 

The  separation  of  the  policy  engine  from  the  mech¬ 
anisms  allows  per-socket  security  selections  and  ad¬ 
ministrative  security  selections  to  be  combined  in 
sophisticated  ways.  For  instance,  an  administrator 
could  require  that  packets  coming  in  on  a  certain 
range  of  privileged  ports  must  come  from  a  privi¬ 
leged  port  and  must  be  authentic  in  order  to  protect 
the  administrator’s  system  from  potential  abuses. 
The  current  policy  engine  only  implements  simple 
system- wide  decisions  (e.g.,  drop  all  non-authentic 
packets,  always  use  authentication  if  we  have  a  secu¬ 
rity  association  that  will  facilitate  it)  in  conjunction 
with  application  requested  socket  security.  Enhance¬ 
ments  to  the  security  policy  engine  are  planned  for 
the  future. 


3.6  Algorithm-independence 

Care  was  taken  to  provide  multiple  levels  of  indirec¬ 
tion  to  take  advantage  of  the  algorithm-independent 
nature  of  the  Authentication  Eleader  and  Encapsu¬ 
lating  Security  Payload  (ESP)  specifications.  Both 
implementations  use  an  algorithm  switch,  which  is 
indexed  by  a  value  in  the  security  association,  to 
support  multiple  algorithms  concurrently  and  allow 
easy  addition  of  new  message  digest  and  encryption 
functions.  This  switch  is  more  complex  for  ESP, 
because  almost  all  of  the  ESP  header  format  can 
change  as  a  function  of  the  transform  in  use.  For  this 
case,  the  switch  allows  implementors  to  specify  the 
header  processing  code  and  the  encryption  code  sep¬ 
arately  for  greater  flexibility.  For  instance,  someone 
wanting  to  substitute  the  IDEA  algorithm  [LM91] 
for  the  default  DES-CBC  algorithm  but  still  use  the 
same  basic  header  format  could  create  a  new  algo¬ 
rithm  switch  entry  that  uses  the  same  header  pro¬ 
cessing  functions  as  DES-CBC  [MKS95a]  but  calls 
the  IDEA  encryption  functions  instead.  Different 
algorithms  will  have  different  performance  impacts. 
Supporting  multiple  algorithms  in  the  kernel  does 
not  exact  a  significant  performance  penalty. 


4  Changes  to  ICMP  and  IGMP 

The  Internet  Control  Message  Protocol  (ICMP)  is 
perhaps  not  as  widely  known  as  TCP  or  UDP,  but 
it  performs  a  critical  function  in  keeping  the  network 
operating  smoothly.  The  Internet  Group  Member¬ 
ship  Protocol  (IGMP)  is  integral  to  IP  multicasting. 
ICMP  for  IPv6  is  sufficiently  different  that  it  is  now 
sometimes  referred  to  as  ICMPv6  [Pos81][DC95]. 

Despite  having  similar  header  syntax,  ICMPv6 
differs  from  ICMP  for  IPv4  in  four  major  ways. 
First,  ICMPv6,  like  TCP  and  UDP,  requires  a 
pseudo-header  to  be  included  in  its  checksum  cal¬ 
culation.  Second,  the  difference  between  informa¬ 
tional  messages  (e.g.  Echo )  and  error  messages  (e.g. 
Port  Unreachable)  is  now  indicated  by  the  high  bit 
in  the  ICMPv6  message  type.  Third,  ICMPv6  ab¬ 
sorbs  the  functions  of  the  formerly  separate  IGMP 
[Dee89],  ARP  [Plu82][FMMT84],  Proxy  ARP,  and 
ICMP  Router  Discovery  [Dee91]  protocols.  Finally, 
ICMPv6  also  adds  support  for  stateless  address 
auto-configuration.  Because  ICMP  is  above  the  IP 
layer,  all  of  these  functions  can  now  be  authenti¬ 
cated  and  or  encrypted  using  the  IP  security  mech¬ 
anisms,  as  long  as  appropriate  security  associations 
exist.  Sites  that  wish  to  bootstrap  securely  can  now 
do  so. 

4.1  Traditional  ICMP  and  IGMP 

ICMPv6  retains  the  functions  traditionally  per¬ 
formed  by  ICMP  and  IGMP.  The  Echo  and  Echo- 
Reply  messages,  utilized  by  ping(8),  are  still  part 
of  ICMPv6.  Unreachability  of  varying  forms  is  in¬ 
dicated  by  the  ICMPv6  Unreachable  message  type. 
Extensions  have  been  added  to  indicate  unreach¬ 
able  on-link  neighbors,  as  well  as  errors  with  strict 
source  routing.  A  Message  Too  Big  message  indi¬ 
cates  when  an  IPv6  datagram  is  too  large  for  a  link 
on  its  path.  Path  MTU  discovery  [MD90],  a  require¬ 
ment  for  IPv6,  is  implemented  using  these  messages. 
Parameter  Problem  messages  indicate  invalid  IPv6 
option  fields,  as  they  do  in  IPv4’s  ICMP.  Time  Ex¬ 
ceeded  messages  indicate  either  a  hop  limit  that  has 
decremented  to  zero,  or  that  an  IPv6  reassembly  has 
timed  out.3 

ICMPv6  has  three  additional  informational  mes¬ 
sages:  Group  Report,  Group  Query,  and  Group  Ter¬ 
minate.  The  first  two  behave  just  like  the  IGMP 
Report  and  Query  messages.  The  Group  Terminate 

3This  implementation  cannot  send  Time  Exceeded  mes- 
sages  for  IPv6  reassembly  timeouts;  the  ” offending  packet” 
needed  for  the  ICMPv6  message  is  no  longer  available  for 
transmission  because  reassembly  is  occurring. 


message  is  an  optimization  so  that  routers  can  be  in¬ 
formed  more  quickly  about  hosts  leaving  multicast 
groups. 

4.2  Address  Auto-Configuration  and 
Router  Discovery 

The  Internet  community  mandated  that  IPv6  sup¬ 
port  simple  address  auto-configuration  for  hosts. 
IPv6  has  two  solutions  to  this  problem.  The  first 
approach  is  to  use  an  optional  configuration  proto¬ 
col,  such  as  DHCPv6.  This  solution  is  beyond  the 
scope  of  this  paper.  The  second  approach,  known  as 
stateless  address  autoconhguration,  is  required,  and 
is  implemented  in  ICMPv6  [TN95]. 

4.2.1  Link-local  Addresses 

When  an  interface  is  configured  for  IPv6,  it  must 
have  a  link-local  address.  A  link-local  address  is 
formed  by  placing  a  link-local  prefix  f  e80  :  :  in  front 
of  a  token,  usually  the  interface’s  MAC  address. 
In  our  implementation,  this  is  done  by  the  ifcon- 
hg(8)  application  placing  this  address  on  an  inter¬ 
face  before  any  other  addresses  are  placed  on  the 
same  interface.  Implementations  must  be  able  to 
detect  whether  their  link-local  address  has  been  du¬ 
plicated  on  the  same  link  (e.g.  Ethernet). [NNS95] 
Our  planned  approach  to  this  collision  detection  is 
discussed  in  the  Neighbor  Discovery  section.  Once 
the  link-local  address  is  verified  as  being  unique 
on  a  link,  the  first  phase  of  stateless  address  auto¬ 
conhguration  is  completed.  The  IPv6  node  can  then 
send  out  ICMPv6  Router  Solicit  messages  to  locate  a 
router,  and  begin  the  second  phase  of  address  auto¬ 
conhguration. 

4.2.2  Router  Discovery 

IPv6  routers  send  out  periodic  Router  Advertise¬ 
ment  messages  to  the  all-nodes  multicast  address. 
Also,  IPv6  routers  send  out  Router  Advertisement 
messages  in  response  to  Router  Solicit  messages.  Be¬ 
sides  performing  the  traditional  jobs  of  IPv4  router 
advertisements,  IPv6  router  advertisements  also  ad¬ 
vertise  parameters  relating  to  Neighbor  Discovery: 
suggested  MTUs  on  variable-MTU  links,  suggested 
maximum  hop  limits,  and  on-link  prehxes. 

It  is  the  advertisement  of  on-link  prehxes  which 
completes  stateless  address  auto-conhguration.  If 
the  Router  Advertisement  message  indicates  that 
stateless  conhguration  is  to  be  performed,  the  mes¬ 
sage  will  also  contain  the  globally  routable  address 
prehx  used  on  the  link.  The  node  then  takes  the 
token  from  its  link-local  address,  and  prepends  the 


advertised  prehx  to  form  an  automatically  config¬ 
ured  globally  routable  address.  The  internal  code  to 
handle  such  advertisements  also  handles  the  manual 
address  conhguration  requests  from  programs  such 
as  ifconhg(8). 

Unlike  IPv4,  IPv6  addresses  can  have  lifetimes. 
In  concert  with  stateless  address  auto-conhguration, 
lifetimes  provide  a  way  for  relatively  rapid  IPv6  ad¬ 
dress  renumbering  to  occur.  Provider-oriented  ad¬ 
dressing  is  one  of  the  address  schemes  that  will  be 
used  with  IPv6.[RLH+95]  With  provider-oriented 
addressing,  the  ability  to  rapidly  renumber  many 
systems  at  a  site  is  essential  if  that  site  should  ever 
want  to  change  network  service  providers.  Hence, 
IPv6  interface  addresses  in  the  kernel  now  contain 
lifetime  helds. 

4.3  Neighbor  Discovery 

IPv6  does  not  use  ARP.4  Instead,  IPv6  uses  mul¬ 
ticasting  and  ICMPv6  to  discover  the  addresses  of 
on-link  neighbors. [NNS95]  Our  implementation  uses 
host  routes  for  on-link  neighbors  and  keeps  link-layer 
information  inside  the  route,  much  as  4.4BSD  im¬ 
plements  ARP  entries.  Like  ARP,  IPv6  neighbor 
discovery  has  the  route’s  gateway  address  point  to 
a  data-link  socket  address,  for  example  an  Ethernet 
MAC  address. 

IPv6  Neighbor  Discovery  is  responsible  for  End¬ 
ing  the  link  address  information  for  the  host  route 
entries.  If  an  IPv6  destination  is  determined  to  be 
on  link,  either  by  matching  an  on-link  prehx  (repre¬ 
sented  as  a  cloning  network  route,  as  IPv4  does),  or 
by  determining  that  there  is  no  other  way  to  reach 
a  destination,  a  neighbor  solicit  is  sent  out  to  a  spe¬ 
cial  multicast  address.  The  special  multicast  rout¬ 
ing  prehx  ff02:  :  1 :  is  prepended  to  the  low  32  bits 
of  the  solicited  neighbor.  All  nodes  automatically 
join  the  Solicited  Nodes  multicast  group  appropri¬ 
ate  for  their  own  addresses.  Broadcast  does  not  exist 
in  IPv6;  multicast  replaces  all  uses  for  broadcast.5 
Once  a  Neighbor  Solicit  is  heard,  enough  informa¬ 
tion  is  known  to  send  a  unicast  Neighbor  Advertise¬ 
ment  to  the  solicitor,  and  now  the  soliciting  node 
knows  that  the  neighbor  is  reachable.  While  the 
solicted  node  has  enough  information  to  return  the 
unicast  neighbor  advertisement,  reachability  the  op¬ 
posite  way  is  not  yet  confirmed.  Unicast  solicit  and 
advertisement  messages  confirm  the  reachability  of 
the  neighbor  after  initial  reachability  is  established. 
Upper-level  protocols  (e.g.  TCP)  can  also  be  used 

4Hence,  ARP-related  broadcast  storm  problems  will  not 
be  present  with  IPv6 

5Hence,  broadcast  storms  will  not  exist  with  IPv6. 


to  provide  reachability  confirmation.6 

Users  can  use  netstat  -r  to  examine  the  state 
of  currently  reachable  and  recently  reachable  neigh¬ 
bor  systems.  This  neighbor  reachability  information 
is  kept  as  part  of  the  routing  table  in  the  kernel, 
so  reachability  updates  for  one  session  to  a  neigh¬ 
bor  will  also  refresh  reachability  for  other  sessions 
to  the  same  neighbor.  Neighbors  that  have  be¬ 
come  unreachable  will  linger  in  the  routing  table  and 
will  eventually  be  marked  with  the  RTF_REJECT  flag. 
This  is  similar  to  the  way  ARP  is  handled  in  4.4-Lite 
BSD. 

Neighbor  discovery  can  be  used  to  detect  the 
uniqueness  of  a  link-local  address.  After  a  link-local 
address  is  configured,  the  node  sends  a  multicast 
neighbor  solicit  for  it’s  proposed  link-local  address. 
If  no  neighbor  responds  with  a  neighbor  advertise¬ 
ment,  then  the  link-local  address  is  unique  for  the 
link.  The  alpha  release  does  not  currently  imple¬ 
ment  collision  detection,  because  of  the  difficulty  in 
placing  the  functionality  of  the  detection.  If  done 
in  the  kernel,  a  user  process  may  be  trapped  in  the 
ioctl(2)  call  for  a  long  time  while  collision  detection 
takes  place.  If  done  in  user  space,  multiple  calls  will 
have  to  be  made  into  the  kernel. 

5  Transport  Layer  Changes 

Both  the  UDP  and  TCP  protocols  remain  un¬ 
changed  for  IPv6.  However,  the  BSD  implemen¬ 
tations  required  modification  to  provide  concurrent 
support  for  IPv4  and  IPv6.  The  main  difficul¬ 
ties  arose  due  to  the  different  sizes  of  the  IPv4 
header  and  the  IPv6  header.  Because  the  TCP  and 
UDP  implementations  are  shared  between  IPv4  and 
IPv6,  we  designed  a  modified  Protocol  Control  Block 
(PCB)  structure  that  supports  both  versions  of  IP. 
Had  the  original  BSD  implementation  of  TCP,  UDP, 
and  IP  not  been  so  closely  coupled,  it  would  have 
been  easier  to  add  IPv6  support  into  the  kernel. 

5.1  Protocol  Control  Block 

Since  TCP  and  UDP  do  not  change  between  IPv4 
and  IPv6,  TCP  and  UDP  use  the  modified  Protocol 
Control  Block  structures  (PCBs)  in  the  same  way. 
With  IPv6’s  larger  address  space,  the  PCBs  were 
modified  to  support  both  IPv4  and  IPv6  addresses 
and  to  denote  which  addresses  are  actually  in  use. 
To  support  both  protocols,  new  unions  were  devised. 
To  make  these  changes  invisible  to  existing  code,  ap¬ 
propriate  #def  ines  were  added  that  silently  derefer- 

6  We  are  still  experimenting  with  the  best  way  for  TCP  to 
update  reachability  without  impairing  performance. 


enced  the  appropriate  component  of  the  union.  Fig¬ 
ure  4  shows  an  example  of  a  new  union  and  its  cor¬ 
responding  new  #defines. 

union  { 

struct  route  ru_route; 
struct  route6  ru_route6; 

}  inp_ru; 

#define  inp_route  inp_ru. route 
#define  inp_route6  inp_ru . route6 

Figure  4:  Route  union  used  in  new  PCB  structure 

The  IPv4-IPv6  transition  specification  [GN95] 
makes  it  easier  to  support  both  protocols  in  a  sin¬ 
gle  PCB  by  allocating  a  portion  of  the  IPv6  address 
space  for  use  as  ”IPv4-mapped”  addresses,  which 
cannot  be  used  as  addresses  in  IPv6  datagrams.  Ad¬ 
ditionally,  if  a  session  is  intending  to  send  IPv6  data¬ 
grams,  a  bit  in  the  session’s  PCB’s  flags  will  be  set 
indicating  this.  If  that  bit  is  not  set,  then  IPv4  is  in 
use.  The  route,  IP  header  template,  and  multicast 
options  elements  now  use  unions  so  that  either  IPv4 
or  IPv6  can  be  used  with  the  PCB. 

New  PCB  functions  were  written  to  support  bind, 
connect,  and  notify  functions  on  PF_INET6  sockets. 
Because  such  a  socket  can  be  used  to  send  and  re¬ 
ceive  either  IPv4  or  IPv6  traffic,  these  functions 
needed  to  be  separate  from  the  equivalent  IPv4  func¬ 
tions  and  also  needed  to  handle  both  versions  of  IP. 
In  the  near  future  we  intend  to  enhance  these  func¬ 
tions  to  fully  support  the  IPv6  Flow  Identifier  held 
so  that  real-time  and  predictive  services  are  provided 
to  applications.  The  in6_pcbnotify()  function  also 
calls  the  input  security  policy  function  to  determine 
whether  a  particular  error  can  be  passed  upwards  to 
the  application  or  whether  that  would  cause  a  secu¬ 
rity  violation  and  the  error  should  not  be  delivered. 

5.2  Changes  in  UDP 

The  UDP  protocol  remains  unchanged  for  IPv6, 
but  the  BSD  implementation  needed  to  be  mod¬ 
ified  to  support  both  versions  of  IP.  The  ma¬ 
jority  of  the  changes  to  the  UDP  code  resulted 
from  the  need  to  support  the  different  address  for¬ 
mat.  The  changes  are  minimal  and  are  isolated  to 
the  following  functions  udp_input  ( ) ,  udp_output  ( ) , 
udp_ctl input  () ,  and  udp_usrreq( ) .  Almost  all 
changes  occur  in  the  input  and  output  process¬ 
ing  of  UDP  datagrams,  handled  by  the  functions 
udp_input  ( )  and  udp_output  ( ) ,  respectively. 


Incoming  UDP  datagrams,  regardless  of  whether 
they  are  transported  over  IPv4  or  IPv6,  are  pro¬ 
cessed  by  udp_input  ( ) .  Where  the  code  needs  to  ac¬ 
cess  elements  of  the  IP  header,  different  code  paths 
are  executed  for  IPv4  and  IPv6  datagrams.  The 
function  relies  on  a  local  variable,  which  it  sets  on 
entrance  to  the  function,  to  determine  which  code 
path  to  follow.  An  example  of  a  code  path  specific 
to  IPv6  is  the  processing  of  an  IPv4  packet  destined 
for  an  IPv6  socket.  The  IPv6  BSD  Sockets  API  spec¬ 
ification  allows  an  application  to  receive  both  IPv4 
and  IPv6  datagrams  using  an  IPv6  socket. [GTB95] 
Code  has  been  added  to  allow  udp_input  ( )  to  han¬ 
dle  this  special  case. 

The  udp_input  ( )  function  now  calls  the  input  se¬ 
curity  policy  function  before  processing  an  incoming 
packet.  This  ensures  compliance  with  both  socket 
and  system  security  requirements.  If  an  incoming 
packet  should  not  be  delivered  for  security  policy 
reasons,  then  it  is  silently  dropped.  This  check  does 
exact  a  performance  penalty  on  each  received  packet, 
but  we  have  not  yet  found  a  better  way  to  handle 
input  security  policy  checks. 

The  function  udp_output  ( )  is  called  to  create  and 
send  a  UDP  datagram.  It  determines  whether  to 
create  an  IPv4  or  IPv6  datagram  by  looking  at 
the  protocol  control  block  for  the  socket  originat¬ 
ing  the  datagram.  If  the  socket’s  protocol  family  is 
PF_INET6  and  the  socket’s  PCB  indicates  that  the 
destination  is  a  native  IPv6  address,  an  IPv6  UDP 
datagram  is  composed  and  sent  down  to  the  IP  layer 
via  the  ipv6_output ( )  function.  If  the  protocol 
family  is  PF_INET,  ip_output()  is  called  instead  of 
ipv6_output.  A  significant  change  in  udp_output() 
from  its  IPv4  version  involves  the  calculation  of  the 
UDP  checksum.  In  IPv4,  calculation  of  the  UDP 
checksum  is  optional  and  is  controlled  by  the  global 
variable  udpcksum.  Since  IPv6  no  longer  has  an  IP 
layer  checksum,  the  UDP  checksum  is  not  optional 
and  must  be  calculated  for  all  IPv6  UDP  packets. 
This  is  necessary  to  provide  integrity  protection  of 
the  source  and  destination  address  that  is  not  pro¬ 
vided  by  IPv6,  which  lacks  an  IP  header  checksum. 

The  remaining  changes  in  udp_ctl  input  ( )  and 
udp_usrreq()  are  minor  changes  to  call  IPv6  ver¬ 
sions  of  certain  IPv4  functions  or  to  initialize  IPv6 
specific  variables  in  the  protocol  control  block.  Over¬ 
all,  the  modifications  of  UDP  code  to  work  with  both 
IPv4  and  IPv6  are  straightforward. 

5.3  Changes  in  TCP 

The  TCP  protocol  also  remains  unchanged  for  IPv6, 
but  was  modified  to  support  both  versions  of  IP. 


One  change  was  to  add  a  new  member,  pf,  to 
the  TCP  control  block  structure,  struct  tcpcb. 
This  new  member  stores  the  Protocol  Family,  either 
PF.INET  for  IPv4  or  PF.INET6  for  IPv6,  in  use  for 
each  TCP  session.  This  is  used  in  several  parts  of 
the  TCP  code  to  help  select  the  correct  IP-specific 
code  branch. 

The  beginning  of  the  tcp_input()  function  has 
a  small  amount  of  IP-related  processing.  This  was 
broken  into  two  code  paths,  one  for  IPv4  and  one  for 
IPv6  at  the  cost  of  an  if  check  and  a  slight  increase 
in  code  size. 

The  main  difficulty  with  the  4.4  BSD-Lite  TCP 
implementation  was  its  reliance  on  a  single  pointer, 
struct  tcpiphdr  *ti,  that  pointed  to  a  structure 
containing  both  the  IPv4  overlay  header  (Figure  5) 
and  also  the  TCP  header  of  received  segments.  The 
tcp_input()  and  tcp_reass()  functions  used  this 
combined  structure  for  most  of  the  data  references 
relating  to  a  given  TCP  segment.  There  were  also 
other  uses  of  this  structure  within  the  TCP  imple¬ 
mentation.  Because  of  the  differing  IP  header  sizes, 
the  TCP  header  starts  at  a  different  offset  from  the 
start  of  the  structure,  depending  on  which  IP  header 
is  present.  The  solution  to  this  problem  was  to  cre¬ 
ate  a  new  pointer  struct  tcphdr  *th  which  is  cal¬ 
culated  separately  for  IPv4  and  IPv6,  but  always 
points  to  the  TCP  header.  The  references  to  TCP 
header  data  that  had  previously  used  *ti  now  use 
*th  instead. 

However,  use  of  the  *th  pointer  did  not  solve  all 
of  the  problems.  The  older  struct  tcpiphdr  con¬ 
tains  an  element  ti->ti  JLen  that  pointed  to  the 
packet’s  length  held.  There  is  not  room  to  store  such 
a  data  item  in  the  struct  tcpipv6hdr,  which  uses  a 
struct  ipv6ovly  (Figure  6),  but  fortunately  there 
was  an  existing  local  variable  tlen  in  tcp_input() 
that  is  used  instead.  Most  of  the  references  to  IP 
data  elements  are  made  at  the  very  beginning  of  the 
tcp_input()  function  and  so  were  easily  handled. 

The  tcp_reass()  function  was  not  amenable  to 
supporting  both  versions  of  IP  at  the  same  time,  so 
our  implementation  increases  code  size  by  adding 
a  new  tcpv6_reass ( )  function  that  uses  struct 
tcpipv6hdr  in  lieu  of  the  struct  tcpiphdr  used 
by  the  original  tcp_reass(). 

The  tcp_input()  function  now  calls  the  input  se¬ 
curity  policy  function  before  processing  an  incom¬ 
ing  TCP  segment.  This  ensures  compliance  with 
both  socket  and  system  security  requirements.  If 
an  incoming  segment  should  not  be  processed  for 
security  policy  reasons,  then  it  is  silently  dropped. 
If  the  system  security  policy  is  to  require  authen- 


ih_next  (pointer  to  next  segment  hdr 


ih_xl  (pad) 


ih_prev  (pointer  to  prev  segment  hdr 


ih_pr  (protocol)' 


ih_len  (length) 


ih_src  (source  address) 
ih_dst  (destination  address) 


Figure  5:  Format  of  struct  ipovly  IPv4  Overlay 

ih_next  (pointer  to  next  segment  header) _ 

ih_prev  (pointer  to  prev  segment  header) 


ih_src  (source  address) 


ih_dst  (destination  address) 


Figure  6:  Format  of  struct  ipv6ovly  IPv6  Overlay 


tication  on  all  received  packets,  then  attempts  to 
open  an  unauthenticated  TCP  connection  or  unau¬ 
thenticated  ping  will  silently  fail  as  if  the  destina¬ 
tion  system  were  not  reachable  at  all.  As  with  the 
UDP  implementation,  this  check  exacts  a  perfor¬ 
mance  penalty. 

One  benefit  of  our  changes  has  been  to  isolate  the 
network-layer  code  more.  This  might  make  it  easier 
to  modify  TCP  further  to  support  TCP  over  other 
network-layer  protocols,  for  example  Novell’s  IPX. 
We  are  concerned  about  the  adverse  performance 
impact  of  the  IPv6  changes,  so  we  are  examining 
methods  of  improving  the  performance  of  our  imple¬ 
mentation.  We  have  not  found  anything  in  the  IPv6 
specifications  that  inherently  reduces  TCP  perfor¬ 
mance. 

6  Changes  to  Applications 

6.1  Network  Socket  Enhancements 

Although  the  IETF  does  not  standardise  applica¬ 
tion  programming  interfaces,  some  members  of  the 
IPng  Working  Group  did  create  an  Informational 
RFC  describing  how  IPv6  might  be  used  in  conjunc¬ 
tion  with  BSD  Sockets  [GTB95].  Some  changes  in 
4.4-Lite  BSD  were  needed  to  comply  with  that  spec¬ 
ification.  Fortunately,  most  of  the  changes  involved 
adding  protocol  switch  tables,  and  entries  to  those 
tables[LMKQ89].  Other  sockets  changes  were  imple¬ 
mented  at  lower  levels,  most  notably  the  aforemen¬ 
tioned  PCB  code.  One  can  use  a  PF_INET6  socket 
to  communicate  using  IPv4  or  IPv6,  which  makes  it 
easier  to  transition  applications  to  the  new  version 


#include  <sys/socket . h> 

#include  <netinet6/in6 . h> 

struct  sockaddr_in6  addr6; 
int  s ; 

s  =  socket (PF_INET6,  SOCK_DGRAM,  0); 
addr6.sin6J.en  =  sizeof (addr6) ; 
addr6 . sin6jf amily  =  AF_INET6; 
addr6 . sin6_port  =  htons(T); 
addr6 . sin6jf lowinf o  =  0; 

(void)  ascii2addr(  AF_INET6, 

"FE80 : : 800: dead: beef", 
&addr 6 . s in6  ^addr ) ; 
sendto(s,  ’’hello’’,  6,  0,  &addr6, 
sizeof (addr6) ) ; 


Figure  7:  Code  fragment  illustrating  use  of  UDP 
over  IPv6 

of  IP. 

More  extensive  changes  were  needed  to 
permit  applications  to  request  security  ser¬ 
vices  from  IPv6.  Several  new  socket  op¬ 
tions  were  defined  and  implemented,  in¬ 
cluding  SO  .SECURITY  JiNCRYPTI  ON  JTtANSPORT, 

SO  J5ECURITY  JiNCRYPTION  JTJNNEL,  and 

S0_SECURITY AUTHENTICATION.  These  new  socket 
options  are  used  by  an  application  to  request  that 
ESP  in  transport-mode,  ESP  in  tunnel-mode,  or  the 


Authentication  Header  be  used  with  this  network 
session.  Each  also  has  an  associated  Security 
Level  parameter.  There  are  currently  4  security 
levels  implemented.  Level  0  does  not  use  security 
on  outbound  packets  and  does  not  require  it  on 
inbound  packets.  Level  1  uses  security  on  outbound 
packets  if  it  is  available  but  does  not  require  it  on 
inbound  packets.  Level  2  requires  security  both 
outbound  and  inbound.  Level  3  is  the  same  as 
level  2  except  that  outbound  packets  use  a  security 
association  unique  to  this  socket.  A  planned 
enhancement  is  to  also  permit  an  application  to 
request  that  its  session  be  provided  with  a  new 
security  association  to  replace  the  one  in  use.  We 
consider  our  new  security-related  socket  options 
experimental  and  may  alter  them  somewhat  as  we 
gain  more  experience  with  application  issues. 

Our  kernel  implementation  permits  a  system  ad¬ 
ministrator  to  define  a  default  or  minimum  level  of 
security.  The  default  security  will  be  used  for  all 
sessions  provided  with  a  valid  Security  Association. 
Applications  may  also  request  security  services  via 
the  above  sockets  extensions.  The  system  security  is 
configured  using  the  same  matrix  of  3  protocols  and 
4  security  levels  that  we  described  earlier  for  use  in 
socket-requested  security.  We  plan  to  enhance  the 
flexibility  of  our  security  policy  engine  in  the  future 
so  that  the  system  administrator  can  have  more  so¬ 
phisticated  policies  than  are  currently  supported. 

6.2  Key  Management  Socket 

We  also  have  defined  a  new  protocol  family,  called 
PFJCEY,  for  the  Sockets  application  programming 
interface.  This  extension  to  Sockets  provides  a 
generic  interface  between  security  association  man¬ 
agement  applications,  such  as  a  Photuris  daemon 
[KS95],  and  the  kernel’s  network  security  data 
structures. [PAM95]  This  new  generic  key  manage¬ 
ment  interface  is  modeled  upon  the  existing  routing 
socket,  PF_R0UTE.[Skl91]  This  enhancement  permits 
the  key  management  system  to  be  completely  decou¬ 
pled  from  the  IP  security  implementation.  Multiple 
key  management  schemes  can  be  supported  concur¬ 
rently  if  desired.  It  also  will  make  it  easy  to  change 
from  one  key  management  algorithm  or  protocol  to 
a  new  key  management  algorithm  or  protocol.  To 
make  such  a  change,  only  a  new  daemon  needs  to  be 
installed;  no  kernel  modifications  or  kernel  rebuild¬ 
ing  is  necessary.  Many  published  key  management 
protocols  have  had  flaws  discovered  years  after  ini¬ 
tial  publication[NS78][DS81].  Hence  it  is  important 
to  be  able  to  easily  change  the  key  management  pro¬ 
tocol  being  used  by  the  system.  Our  alpha  release 


includes  an  application,  key (8),  that  can  be  used  by 
the  system  administrator  to  manage  keys  and  secu¬ 
rity  associations  in  the  kernel.  Any  key  management 
scheme,  whether  automatic  key  management  such  as 
Photuris  or  manual  key  management  such  as  key (8), 
can  use  the  PFJCEY  interface. 

6.3  An  Example  Application:  telnet 

Most  applications  will  need  a  small  amount  of  mod¬ 
ification  to  take  advantage  of  IPv6  and  its  unique 
features.  Even  with  these  modifications,  the  appli¬ 
cations  will  continue  to  support  IPv4.  Most  of  these 
modifications  are  in  the  socket  code,  allowing  the  use 
of  the  new  AF_INET6  address  family,  new  data  struc¬ 
tures,  and  the  corresponding  network  functions. 

We  have  modified  several  applications  to  use  IPv6. 
We  describe  the  modifications  required  for  telnet  in 
the  following  paragraphs.  The  telnet  application  was 
also  enhanced  to  add  command-line  options  to  set 
the  socket  security  level.  7 

The  telnet  client  first  parses  the  command  line 
and  options.  If  the  user  has  requested  IP  secu¬ 
rity  services,  then  the  appropriate  socket  options  are 
set  using  setsockopt  ( ) .  Telnet  then  uses  the  new 
hostname2addr()  and  ascii2addr()  functions  to 
seek  an  IPv6  address  for  the  specified  hostname  or 
text  representation  of  an  address.  If  an  IPv6  address 
is  returned,  telnet  then  opens  a  PF_INET6  socket  and 
begins  communicating.  The  requested  security  ser¬ 
vices  are  automatically  applied  by  the  IP  security 
implementation  inside  the  kernel.  If  an  IP  security 
processing  error  (for  example,  no  security  associa¬ 
tion  can  be  found  and  one  is  needed)  occurs,  then 
the  EIPSEC  error  will  be  returned  to  telnet  so  the 
user  can  be  informed  of  the  problem. 

The  IPv4  library  functions  inet_ntoa(), 
inet^atonO,  gethostbyname  ( ) ,  and 

gethostbyaddrO  have  been  superceded  by  the  new 
library  functions  addr2ascii ( ) ,  ascii2addr(), 
hostname2addr(),  and  addr2hostname ( ) 
[GTB95].8  These  new  library  functions  work 
equally  well  for  both  IPv4  and  IPv6,  making  it 
easier  for  applications  to  support  both  IPv4  and 
also  IPv6. 

In  the  future,  we  plan  to  add  a  privileged  socket 
option  to  permit  applications  that  need  to  bypass  IP 
security  to  do  so  (for  example,  a  Photuris  daemon). 
This  socket  option  would  fail  if  the  effective  user-id 
of  the  process  connected  to  the  socket  was  not  equal 

^Although  4.4  BSD’s  telnet  includes  an  encryption  option, 
a  fatal  implementation  flaw  limits  its  practical  value. 

8These  new  functions  were  originally  suggested  by  Craig 
Partridge  in  an  email  note  to  the  IETF’s  IPng  mailing  list. 


to  0  so  that  ordinary  user  applications  could  not  by¬ 
pass  system  security.  Such  bypass  is  needed  by  key 
management  applications  so  that  they  can  create  the 
initial  security  associations.  Certain  other  applica¬ 
tions  having  application-layer  security,  for  example 
a  secured  Domain  Name  Service  daemon,  might  also 
need  to  bypass  IP  security  services.  Although  this 
has  not  been  implemented  yet,  we  believe  it  will  be 
straight  forward  to  implement  and  have  already  put 
some  of  the  hooks  in  place. 

7  Performance 

Throughput  and  round-trip  latency  were  measured 
using  Rick  Jones’  NetPerf  t.ool.[Jon95]  Net.Perf  has 
more  accuracy  and  reproducibility  than  some  older 
tools. [Jef95]  Except  for  Table  5,  these  measurements 
are  for  traffic  that  is  neither  authenticated  nor  en¬ 
crypted,  though  the  security  policy  checks  are  still 
performed. 


Number 
of  bytes. 

IPv4. 

(msec). 

IPv6. 

(msec). 

Percent 

increase. 

1 

1.27 

1.54 

+21% 

64 

1.45 

1.83 

+26% 

1024 

3.12 

3.62 

+  16% 

2048 

5.34 

6.01 

+  12% 

4096 

10.4 

11.9 

+  14% 

8192 

19.0 

22.1 

+  16% 

Table  1:  TCP  Latency 


Number  of 
bytes. 

IPv4. 

(msec). 

IPv6. 

(msec). 

Percent 

increase. 

1 

0.93 

1.08 

+17% 

64 

1.13 

1.30 

+15% 

1024 

2.82 

3.06 

+8% 

2048 

5.00 

5.77 

+15% 

4096 

8.89 

9.90 

+11% 

8192 

17.0 

20.2 

+19% 

Table  2:  UDP  Latency 
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TCP/IP 

TCP/IPv6 


around  the  preparsing  code  in  the  future.  The  lower 
IPv6  throughput,  shown  in  Table  3  and  Table  4,  is 
due  to  increased  latency  and  larger  packet  size. 

The  4.4-Lite  BSD  implementation  of  TCP/IPv4 
has  had  years  of  optimisation  whilst  our  alpha  re¬ 
lease  has  had  no  optimisation.  We  believe  that  an 
optimised  IPv6  implementation  will  perform  at  least, 
as  well  as  a  similarly  optimised  IPv4  implementa¬ 
tion. 


25  - 


Figure  8:  UDP  and  TCP  Latency  Graphs 

In  our  alpha  release,  IPv6  performance  is  some¬ 
what  worse  than  IPv4.  UDP  latency,  shown  in  Ta¬ 
ble  2,  and  TCP  latency,  shown  in  Table  1,  both  in¬ 
creased  for  IPv6.  The  increased  latency,  shown  in 
Figure  8  is  in  both  the  inbound  and  outbound  pro¬ 
tocol  processing.  Comparing  longer  addresses  (four 
32-bit.  words  vs.  a  single  32-bit.  word)  and  preparsing 
of  optional  headers  are  the  major  contributors  to  the 
increased  latency.  We  plan  to  add  a.  fast  path  bypass 


Data 

size 

Socket 
buffer  size 

IPv4 

(KB/sec) 

IPv6 

(KB/sec) 

Perf. 

drop 

4096 

57344 

780 

731 

6.26% 

8192 

57344 

778 

729 

6.28% 

32768 

57344 

776 

730 

5.97% 

4096 

32768 

807 

763 

5.45% 

8192 

32768 

806 

758 

5.91% 

32768 

32768 

811 

762 

6.02% 

4096 

8192 

861 

775 

9.93% 

8192 

8192 

858 

784 

8.68% 

32768 

8192 

863 

784 

9.19% 

Table  3:  TCP  Throughput. 


Net.Perf  has  not  yet.  been  modified  to  use  the  se¬ 
curity  socket,  options.  Making  such  modifications  to 
Net.Perf  does  not.  appear  trivial.  The  older  ttcp(8) 
testing  tool  was  easily  modified  to  use  the  security 
socket  options.  Table  5  indicates  throughput  differ¬ 
ences  (measured  with  ttcp(8))  using  authentication, 
transport-mode  encryption,  and  both,  versus  no  se¬ 
curity  at  all.  While  we  have  less  confidence  in  the 


Data 

Socket 

IPv4 

IPv6 

Perf. 

size 

buffer  size 

(KB/sec) 

(KB/sec) 

drop 

64 

32767 

537 

500 

6.82% 

1024 

32767 

1144 

1125 

1.60% 

Table  4:  UDP  Throughput 


absolute  values  for  ttcp(8)  than  for  NetPerf,  we  be¬ 
lieve  the  relative  performance  degradation  shown  by 
ttcp(8)  is  meaningful.  Our  security  implementations 
have  not  been  optimised  at  all.  We  believe  that  we 
can  noticably  improve  our  encryption  performance 
by  encrypting  and  decrypting  in  place  and  removing 
memory  copies.  Hardware  implementations  of  DES 
that  run  at  1  Gbps  exist. [Sch94]  Implementations 
seeking  high  performance  should  probably  use  such 
encryption  hardware. 


Security 

Features 

Throughput 

(KB/sec) 

None 

"775 

Authentication 

"345 

Encryption 

"192 

Both 

"153 

Table  5:  Impact  of  IPv6  Security  On  Throughput. 


8  Summary 

This  paper  has  described  a  freely  distributable  pro¬ 
totype  implementation  of  IPv6  based  on  4.4  BSD- 
Lite.  There  are  a  number  of  implementation  differ¬ 
ences  between  IPv4  and  IPv6  due  to  packet  format 
differences  and  also  protocol  differences.  Some  of 
the  assumptions  made  and  techniques  used  by  the 
IPv4  implementation  are  no  longer  valid  for  IPv6. 
Because  the  implementation  includes  the  crypto¬ 
graphic  security  mechanisms  mandatory  for  IPv6, 
any  networked  application  can  now  have  the  secu¬ 
rity  it  desires  without  having  to  implement  it  at  the 
application  layer.  Performance  of  TCP/IPv4  and 
TCP/IPv6  has  been  compared. 
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